NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part2/16955

Internet Message Format | 1996-08-05 | 10.6 KB

Path: wholder2.cts.com!user
From: [e-mail] (Doug Bell)
Newsgroups: comp.lang.java,comp.lang.c++,comp.lang.smalltalk
Subject: Re: Will Java kill C++?
Date: Fri, 12 Apr 1996 15:08:45 -0700
Organization: FTL Games
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
NNTP-Posting-Host: wholder2.cts.com

In article <[e-mail]>, [e-mail] wrote:

> Doug Bell wrote:
> >
> > In article <[e-mail]>, [e-mail] wrote:
> >
> > > Would you consider VisualBasic to be a workhorse language?  Are there
> > > or are there not many useful programs written in VisualBasic that
> > > are widely-used?
> >
> > Yes.  And yes.
>
> If both Java and VisualBasic are suitable as "workhorse languages," what
> is it that disqualifies Smalltalk?

Well, you left out my definition of workhorse language from my post:

"I would define a 'workhorse' language to be one which is used by a large
body of people to produce useful software which is used on a regular
basis."

*Maybe* Smalltalk has grown into this role (from the number of people
jumping on me for my original post, I might consider this :), but you tell
me: Does Smalltalk meet that definition?  Honestly, now, is there a "large
body of people" using it?

> > Why would you assume that the match between the technical merits of
> > Smalltalk and the requirements of the project *don't* have anything to do
> > with it not being accepted on a broader basis?
>
> Why would you assume there was a particularly strong correlation between
> these things?  It's possible to be dumb and lazy--but rich.  And it's possible
> to be smart and hard-working--but poor.  There are many reasons for this,
> but the most important one is that the competitors don't start the game
> at the same time with equal initial stakes.  Such is the case with
technologies
> and programming languages.  A ten-year head start can be parlayed into an
> almost impregnable market position.  It's not just how good is the language,
> but how widely used it is.  How easy it is to get trained, experienced talent.
> The availability of mature, tested code libraries.  The loyalty of hordes
> of dedicated users who want to capitalize on their ten years of experience
> in the old language instead of being newbies in a new, unproven language.

Keep going, you're making my point rather well...

> Also, the environment in which the competition takes place is undergoing
> constant, rapid change.  Smalltalk was simply not as viable ten years ago,
> or even five years ago, as it is today, because of its memory footprint
> and reliance on a virtual machine.  Imagine if this were 1986, and Sun
> had just introduced Java! Imagine the excitement of running Java...on
> a virtual machine...on a 16Mhz 386 with 640k of memory...with no virtual
> memory...in real mode...

If Java was introduced in 1986, it would have failed because it did not
meet the criteria I set forth for a tool to be successful.  The worth of
the tool is not independent of the environment and existing conditions in
which it is deployed.

> Smalltalk's age is irrelevant. What is relevant is that the ever-increasing
> capabilities and performance of the hardware have made it suddenly very
> viable--so much so, that a language with very similar performance constraints
> and resource requirements is now the hottest computer language in two
> decades.

Well, I think you miss the big picture if you are going to compare Java's
resource requirements to Smalltalk's.  Interpreted Java is a transistion
which I suspect will be left behind sooner rather than later.  The
resource requirements of Java should actually be lighter than those of
several conventional languages, with perhaps an exception made for it's
less efficient use of memory than most conventional languages.

I wouldn't be interested in Java if I thought that the Java we have today
was the Java we will have in six to nine months.  If I though it was going
to be ten years before Java's current resource short-comings were
addressed, I'd also not be interested, at least not for ten years, at
which time I suspect there would be something more relevant to the current
environment than Java which would warrant my attention.  ;)

>>>>> But the reason a language such as Smalltalk
>>>>> is not used in most cases has more to do with prejudice, ignorance,
politics,
>>>>> inertia and the tendency to copy what others are doing than it does
with the
>>>>> technical merits of Smalltalk or the requirements of the project.
>>>>
>>>> Now you're starting to sound like the guy I was originally responding to.
>>>> Let's just say that to some extent, the answers a language *does* have
>>>> must be relative to the impact of the software which results from it.
>>>> What other measure would you apply?
>>>
>>> I would say that the impact of the software implemented in a language
>>> is the **intersection** (NOT the **union**) of the power of the language,
>>> the talent of those using it, and the assignments that the language gets
>>> dealt by the market.  Once one tool achieves dominance, it is very difficult
>>> for other incompatible tools to become widely used--regardless of relative
>>> merit (e.g., Windows, x86, S360/370, gasoline, chinese ideographs, etc).
>>> So very good tools can have relatively small impact--because they don't
>>> get used.
>>
>> Here is the crux of the issue.  If a tool can't meet the requirements
>> necessary to fit the demands of the market, pool of available talent, and
>> integration with existing systems and infrastructure, then that is the
>> fault of the tool, not the fault of the conditions under which it must be
>> deployed.  The technical merits of the tool can only be properly judged in
>> the environment in which it is to be deployed, not in the confines of the
>> laboratory.
>
> If "a tool can't meet the requirements necessary to fit the demands of the
> market" because of its technical shortcomings, then you have a point.  If
> the tool is rejected by the market because a) there was not a sufficient
> supply of trained/experienced talent; b) the market had no confidence in
> the tool because it was not blessed by <insert name of market-dominating
> company of your choice here>; or c) because the market was going ga-ga over
> some other tool that was no better (perhaps even worse) than another, and was
> in no mood to even hear about any tool other than the one it had become
> infatuated with--then you can't really blame the tool for being no good,
> can you?

I'm not "blaming" Smalltalk.  As you and others have pointed out, there
are environments and projects for which Smalltalk is apporpriate.  But
Smalltalk had all the advantages (time to mature and innovate, dedicated
group of proponents, real-world application) over Java to be what Java is
(net-based, providing a solution for which there is a demand, and easy to
learn and assimilate for a large base of programmers), and failed.  So
Java is the better tool for many projects than Smalltalk for these
reasons.

Now if the Smalltalk people want to quit sulking over Java's sudden and
rapid interest and do something to change the situation for the better,
they should figure out how to adapt Smalltalk to this task.  If you build
it, they will come.  If they don't come, you haven't built what they
need.  It's not politics and the stupidity of the masses, it's survival of
the fittest and the fitness of the tool.

To give a short analogy (please no flames on this, that belongs in a
different newsgroup), I use a Mac.  I am convinced that a Mac is a better
tool than a Windows-based PC.  Why, then, is not the Mac the dominant
tool?  Two reasons: 1) it was too expensive for a long time; and 2) it was
not an open system and the pace of innovation was limited to a large
extent to what Apple could manage.  I blame the tool for this.  It doesn't
stop me from trying to promote it, but I don't blame everyone who bought a
PC for the failings of the Mac.  Nor do I mark it up to "prejudice,
ignorance, politics, inertia and the tendency to copy what others are
doing".

> (However, I have always thought that
> C could be much improved upon, so that it would be an even better high-level,
> statically-typed assembly language: I'd start by changing the type declaration
> syntax so that it was more like that of Modula-2).

Sure, C is *far* from perfect.  As knowledge advances, shortcomings will
become apparent in any technology.

> But you should use a language such as Smalltalk (there are other languages
> that are more or less comparable technically) for most custom business
> applications.  There is a reason that this market is dominated by languages
> such as COBOL, RPG, VisualBasic, Delphi, PowerBuilder, Forte and Smalltalk,
> all of which are very different than C.

But it doesn't follow that you should use Samlltalk whereever you might
consider using Java, which is what some in this thread have seemed to
suggest.

> No one language is right for every and all tasks.

Ahhh, harmony!  We certainly agree here.

>>> Example: one could use modern linguistic science to design a much better
>>> language than English or any other natural language.  Aren't you excited
>>> by the prospect of using such a language?  I know, you just can't wait
>>> to learn and start using this language.  Right?
>>
>> Wrong.  Your natural language doesn't meet the requirements necessary to
>> fit the demands of the market, pool of available talent, and integration
>> with existing systems and infrastructure, so it isn't a better tool than
>> the existing language, despite it's technical merits.
>
> Precisely my point.  The corollary is that the fact that a tool has failed
> in the market does not prove that the tool is technically flawed, or that
> it could not possibly be much better from a technical standpoint than the
> more popular tools.
>
> --Alan

Well, it's really a difference of symantecs here, but the technical
evaluation includes, IMHO, the suitability to the environment.  For
example, your hypothetical language could either be designed to accomplish
it's technical improvement AND be as familiar as possible to current users
of English, or it could be designed purely on linguistic merits with no
compromises to the existing base of users.  Which would be the
"technically superior" language?  It would depend, in part, on how you
define "technically superior".

Doug Bell
[e-mail]